D0b
D-D0b Layout Preview
Uebersicht Full Page D01 D02 D03 D04 D05 D06 D07 D08 D09

Versioned reference preview

Layout, spacing and sizing decisions

This page preserves the visual examples used for D-D0b. It helps review spacing, widths, vertical rhythm and density, but the Markdown standards are the source of truth.

Kept intentionally: this HTML preview is stored with the D-D0b planning files for visual review. Final rules live in the Obsidian Markdown files and in the Subframe UI Standards.

Was du hier validierst

Diese Seite ist jetzt als Entscheidungsstrecke aufgebaut. Jede Entscheidung hat eine Nummer, eine konkrete Frage und sichtbare Beispiele darunter.

Full Page Preview Oeffnet eine eigene Full-Page-Dummyseite mit App Shell und Layout-Umschaltern. D01 Grundraster Welche Abstandsskala ist unser Standard? D02 Page & Card Padding Wie viel Luft bekommen Seiten und Panels? D03 Text-Rhythmus Wie nah stehen Titel, Beschreibung und Inhalt? D04 Button Ownership Button-Groessen kommen aus der Button-Komponente. D05 Forms Form-Feldgruppen stehen standardmaessig 16px auseinander. D06 Table Ownership Tabellen-Dichte kommt aus der Table-Komponente. D07 Dialoge Welche Breiten gelten fuer kleine, normale und grosse Modale? D08 Dialog Internal Gaps Welche Abstaende gelten innerhalb normaler Dialoge? D09 States States sind inline Komponenten-Zustaende, keine eigenen Layout-Screens.

D01 Grundraster / Spacing Scale

Validierter 8px-Rhythmus mit erlaubten Zwischenwerten. Nutze diese Ansicht als visuelle Referenz fuer die freigegebenen Layout-Abstaende.

Entscheidung D01

Was du festlegst

Welche Abstandsskala darf in HiveGrid verwendet werden?

Das ist die Grundlage fuer alle weiteren Padding- und Gap-Entscheidungen. Eine kleine Skala macht Screens konsistenter.

Sehr streng Nur 8, 16, 24, 32, 48, 64. Sehr sauber, aber manchmal zu grob.
8px Rhythmus + Ausnahmen 4, 8, 12, 16, 24, 32, 48, 64. Praktisch fuer echte UI-Arbeit.
Sehr frei Viele Zwischenwerte erlaubt. Flexibel, aber weniger konsistent.
Entscheidung: Darf HiveGrid den 8px-Rhythmus mit 4px/12px-Ausnahmen nutzen?
4px

Tiny relation

8px

Label to field

12px

Compact groups

16px

Related items

24px

Card padding

32px

Section gap

48px

Large break

64px

Major break

D02 Page, Card und Grid Padding

Lila Flaechen zeigen Innenabstand. Das ist der Abstand zwischen dem Rand eines Containers und seinem Inhalt. Tuerkise Flaechen zeigen Gap: Abstand zwischen getrennten Elementen.

Padding / Innenabstand Gap / Abstand zwischen Elementen Inhalt / Content
Entscheidung D02

Was du festlegst

Wie viel Abstand bekommen Page-Container, Cards/Surfaces und Card-/Grid-Abstaende?

Diese Entscheidung bestimmt, ob HiveGrid eher kompakt, neutral oder luftig wirkt. Es geht um sichtbare Layout-Standards, aber Komponenten-Defaults bleiben fuehrend, wenn sie das Padding bereits korrekt mitbringen.

Kompakt Page bleibt 24px min, Card 16px, Grid Gap 12px. Nur fuer enge Teilbereiche.
Entschieden: Admin Standard Page 24px, Card 16px, Grid Gap 16px. Gilt fuer Standard Desktop und kompakte Settings.
Dialog-Variante 32px ist kein freier Surface-Standard, aber als eigene Dialog-Variante erlaubt.
Entschieden: Page Padding ist immer mindestens 24px. Card/Surface Padding bleibt 16px. Grid/Card Gap ist standardmaessig 16px und kann in kompakten Teilbereichen auf 12px reduziert werden. Grosse Detail-/Editorflaechen starten ebenfalls mit 16px; 32px ist nur ueber die eigene Dialog-Variante erlaubt.
Carbon-Orientierung
  • Carbon arbeitet mit einer kontrollierten Spacing Scale.
  • 8px ist die zentrale Rhythmik, 16px kommt sehr haeufig vor.
  • Layout-Abstaende und Komponenten-Innenabstaende werden getrennt betrachtet.
HiveGrid-Regel fuer Subframe

Die Werte unten sind Zielwerte fuer das sichtbare Layout. Wenn Dialog, Card, Table, Button oder Input das passende Padding schon intern haben, wird dieses Komponenten-Padding genutzt und nicht manuell nachgebaut.

App Shell

Navigation, Sidebar, Topbar und der aeussere Content-Viewport. Die App Shell hat nicht einfach einen Page Gap; sie stellt den Bereich bereit, in dem die Seite liegt.

Page Padding

Innenabstand innerhalb des Page-Contents nach der App Shell. Dieser Abstand verhindert, dass Inhalt direkt am Shell-Rand oder Browserrand klebt.

Section / Grid Gap

Abstand zwischen getrennten Bereichen, Sections, Karten oder Spalten. Das ist kein aeusserer Seitenrand.

Schmaler Screen

Wenn der verfuegbare Content-Bereich kleiner wird, bleibt der Desktop-/Settings-Mindestabstand erstmal bei 24px. Danach muessen Layouts umbrechen, stacken oder horizontal scrollen.

Vergleich 1: Page Padding

Das ist der Abstand vom Page-Content-Rand nach innen. Die App Shell selbst ist hier nicht gemeint.

16px Sonderfall kompakt
16px
24px Empfohlen fuer Admin
24px
32px Ruhigere Flaechen
32px

Vergleich 2: Card / Surface Padding

Das ist Innenabstand innerhalb von Cards, Panels oder groesseren Surface-Bereichen.

16px Kompakte Cards
16px
24px Standard Cards
24px
32px Editor / Detail
32px

Vergleich 3: Grid / Card Gap

Das ist der Abstand zwischen Karten, Spalten oder zusammengehoerigen Layout-Bloecken.

12px Sehr dicht
Card A
Card B
Card C
16px Empfohlen
Card A
Card B
Card C
24px Getrennte Bereiche
Card A
Card B
Card C

Standard Desktop Page

Normale App-/Admin-Seite
Page 24px
Card 16px
Card 16px
Page padding 24px Card padding 16px Card gap 16px

Kompakte Settings Page

Settings, Admin-Listen, dichter Kontext
Page 24px
Card 16px
Card 16px
Page padding 24px Compact card 16px Gap 16px

Dialog-Variante: grosse Detail-/Editor-Flaeche

Nur ueber Dialog-Komponente
Dialog 32px
Surface 32px
Dialog spacious 32px nur als Dialog-Variante D02 final bleibt 16px
Padding

Fachlich: Innenabstand. Er liegt innerhalb einer Flaeche, Karte, Surface oder eines Containers. Padding sorgt dafuer, dass Inhalt nicht direkt am Rand klebt.

Gap

Fachlich: Zwischenraum in einem Layout. Gap liegt zwischen mehreren Elementen, zum Beispiel zwischen zwei Karten oder zwischen Formularfeldern.

Margin

Fachlich: Aussenabstand. Margin schiebt ein Element von anderen Bereichen weg. In unserem Layout-Lab nutzen wir meistens Gap, weil es in Auto Layout besser kontrollierbar ist.

Page Padding Benutzt am aeusseren Seitenrand.
24px
Page content

Der Inhalt beginnt nicht direkt am Browser-/Shell-Rand, sondern nach dem Page Padding.

Card / Surface Padding Benutzt in Karten, Panels und Surfaces.
16px
Card / surface content

Text, Aktionen oder Formularfelder haben Luft zum Rand.

Grid / Card Gap Kein Padding: Abstand zwischen Karten.
Card 1
Card 2
Card 3

D03 Text-Rhythmus

Text-Rhythmus meint vertikale Abstaende zwischen Textbloecken: zum Beispiel Page Title, Beschreibung und erstem Content. Die Beispiele nutzen echte Text-Tokens, weil Line-height die sichtbare Hoehe eines Textblocks veraendert.

Entscheidung D03

Was du festlegst

Wie eng stehen Textbloecke und der erste Inhalt zusammen?

D03 ist validiert. Die Regel betrifft die vertikalen Gaps zwischen gerenderten Textbloecken und Inhalt. Beschreibende Page- und Section-Texte muessen 150%-Texttokens nutzen, weil die Line-height die optische Hoehe des Blocks beeinflusst.

Title -> Description Header -> First content Section title -> Section description Description -> Section content Tokens: Heading / Body 150
Sehr kompakt 0px / 16px / 0px / 8px. Sehr dicht, nur fuer stark verdichtete Teilbereiche.
Token-aware Standard 0px / 24px / 0px / 12px. Finaler Vorschlag mit 150%-Texttokens.
Luftig 0px / 32px / 0px / 16px. Ruhiger, aber nimmt in Settings mehr Platz weg.
Validiert: D03 nutzt 0px zwischen Titel und Beschreibung, 24px bis zum ersten Content, 0px zwischen Section Title und Beschreibung sowie 12px zwischen Section Beschreibung und Inhalt. Page-/Section- Beschreibungen muessen dafuer 150%-Texttokens nutzen.
Option A: Sehr kompakt Dicht, scanbar, wenig Ruhe.
A
Settings

Mitarbeiter

Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.

Aktive Mitarbeiter

Die Liste zeigt eingeladene und aktive Nutzer.

12 aktiv
3 offen
Option B: Token-aware Standard Finaler Arbeitsstandard mit 150%-Texttokens.
B
Settings

Mitarbeiter

Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.

Aktive Mitarbeiter

Die Liste zeigt eingeladene und aktive Nutzer.

12 aktiv
3 offen
Option C: Luftig Ruhiger, aber weniger dicht.
C
Settings

Mitarbeiter

Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.

Aktive Mitarbeiter

Die Liste zeigt eingeladene und aktive Nutzer.

12 aktiv
3 offen

Was D03 regelt

Page- und Section-Textbloecke

D03 entscheidet die Gaps zwischen Text und Inhalt, damit Screens gleich getaktet wirken. Die Inputs, Buttons, Tabellen und Cards behalten ihre eigenen Komponentenabstaende.

Page Title zu Beschreibung 0px definiert
Page Header zu erstem Content 24px
Section Title zu Beschreibung 0px definiert
Section Beschreibung zu Inhalt 12px

Nicht Teil von D03

Keine Typography- oder Komponentenentscheidung

Textgroessen, 150%-Line-height bei mehrzeiligem Text, Input-Label-Abstaende, Tabellenzeilen und Button-Hoehen bleiben in den jeweiligen Tokens oder Komponenten. D03 soll nur klaeren, wie Page-/Section-Text gegen den Content rhythmisiert wird.

Wrap-Risiko

`body-default-regular-0`

16px Text / 17px Line-height. Gut fuer echte Einzeiler, aber eng sobald Text umbricht.

Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.

Wrap-sicher

`body-default-regular-150`

16px Text / 24px Line-height. Besser fuer Texte, die ein- oder mehrzeilig sein koennen.

Verwalte Einladungen, Rollen und Status fuer alle Personen im Workspace.

Regel-Kandidat fuer Text-Wrapping

Wenn Text umbrechen kann, nutzt er einen 150%-Token.

D03 nutzt bewusst 0px zwischen Titel und Beschreibung, weil der 150%-Texttoken bereits genug optische Hoehe im Textblock erzeugt. Diese 0px sind ein definierter Auto-Layout-Gap und kein fehlender Abstand. Wenn ein Description-Text von einer auf zwei Zeilen springt, wird nur der Textblock hoeher. Der Gap zum naechsten Content bleibt 24px im Page Header oder 12px in Sections.

D04 Button Component Ownership

Button-Hoehen, Innenpadding und Varianten werden durch die Button-Komponente abgedeckt, nicht durch Screen-Layout-Regeln.

Komponenten-Ownership

Was fuer Screens gilt

Standardaktionen nutzen die Default-Variante der Button-Komponente.

Die Default-Variante ist `Medium` und 36px hoch. Screen-Prompts sollen Button-Hoehen oder Button-Padding nicht manuell nachbauen.

Small 32px. Kommt aus der Komponente und wird nur genutzt, wenn der Kontext klein/dicht ist.
Medium / Default 36px. Standard fuer normale lokale Aktionen in Screens.
Large 48px. Kommt aus der Komponente und wird nur bewusst eingesetzt.
Keine eigene D04-Layoutentscheidung: Button Default/Medium 36px fuer Standardaktionen verwenden.

Small, 32px high

Save Cancel More

Medium / Default, 36px high

Save changes Cancel

Large, 48px high

Create workspace Delete

D05 Form Layout Gap

Formular-Layout meint hier nur den Abstand zwischen kompletten Field-Komponenten. Label, Beschreibung, Control und Message gehoeren zur jeweiligen Form-Input-Komponente.

Entscheidung D05

Was du festlegst

Wie dicht stehen komplette Formularfelder bzw. Field-Komponenten?

Validiert: komplette Field-Komponenten stehen standardmaessig 16px auseinander. Beschreibung/Help/Error wird innerhalb der Komponente ueber deren Props/Slots gepflegt.

Kompakter Sonderfall 12px nur fuer sehr dichte Teilbereiche, nicht als Formularstandard.
Standard 16px zwischen kompletten Field-Komponenten.
Luftig 24px nur fuer bewusst getrennte Formular-Sections.
Entschieden: Form Field Gap 16px. Field-Anatomy selbst kommt aus der jeweiligen Komponente.

Standard form density

Visible to all members in this workspace.

Use at least 12 characters.

Save Cancel

Compact form density

Update profile Reset

D06 Table Component Ownership

Tabellen-Row-Height, Cell Padding und Header-Dichte gehoeren zur Table-Komponente. D-D0b dokumentiert nur die Referenzlogik fuer Screen-Prompts.

Filter Invite
Komponenten-Ownership

Carbon-Referenz

Die Table-Komponente fuehrt die Dichte; Screens bauen keine Tabellen-Paddings manuell.

IBM Carbon arbeitet bei Data Tables mit mehreren Row Sizes. Die Werte sind xs 24px, sm 32px, md 40px, lg 48px und xl 64px. Columns haben 16px Padding. Die Header Row soll zur Tabellen-Row-Groesse passen; sehr grosse Rows sind fuer zwei Inhaltszeilen gedacht.

Carbon kompakt XS/SM fuer sehr dichte Datenlisten, wenn die Table-Komponente das anbietet.
Carbon Standard MD/LG als normale Table-Dichte; Header, Row und Toolbar muessen zusammenpassen.
Carbon gross XL nur, wenn zwei Zeilen Inhalt oder bewusst mehr Leseraum gebraucht wird.
Keine eigene D06-Layoutentscheidung: Table-Komponente nutzen; Carbon als Referenz fuer passende Row-Size-Systematik.
Name Role Department Status Actions
David Bertram Admin Operations Active ...
Anna Keller Finance Lead Finance Active ...
Max Hoffmann Employee Support Pending ...

D07 Dialog Sizes

Validierte Breiten fuer zentrierte Dialoge und Fullscreen Dialoge. In Subframe muessen diese Beispiele mit echten Dialog Layouts gebaut werden.

Entscheidung D07

Was du festlegst

Welche Breiten bekommen kleine, normale und grosse Dialoge?

Dialogbreite und Dialogpadding sind getrennte Entscheidungen. Die Beispiele unten zeigen Breitenklassen und die zwei validierten Dialog-Padding-Varianten.

XS / S XS 420px fuer kurze Bestaetigung, S 560px fuer kleine Formulare.
M / L M 720px fuer normale Formulare, L 1200px max fuer grosse Editor-Dialoge.
Fullscreen Fill in Breite und Hoehe mit 24px aeusserem Rand, aber maximal 2512px breit.
Entschieden: XS 420px, S 560px, M 720px, L 1200px max. Fullscreen Dialog nutzt Fill mit 24px aeusserem Rand pro Seite und `max-width: 2512px`.
Page

Eigener App-Ort mit Navigation oder Subnavigation. Settings ist eine Page, kein Dialog.

Dialog

Temporäres Overlay ueber der Page. Blockiert den Hintergrund und wird wieder geschlossen.

Fullscreen Dialog

Fill in Breite und Hoehe mit aeusserem Rand und 2512px Maxbreite. Wird geschlossen und ist kein dauerhafter App-Bereich.

Drawer / Side Panel

Seitliche Bearbeitung, waehrend der Kontext sichtbar bleibt. Eigene Breitenregeln, nicht D07.

Validierte zentrierte Dialoggroessen

Vier neutrale Groessen fuer Confirm, kleine Formulare, normale Formulare und grosse Editor-Dialoge.

Validiert
XS420px
420
S560px
560
M720px
720
L1200px max
1200

Verhalten auf breiten Monitoren

Dialoge wachsen nicht automatisch mit 4K-Viewports mit. Die Breitenklasse bleibt fix, der Dialog bleibt zentriert und der aeussere Overlay-Abstand wird groesser. Fullscreen Dialoge nutzen `width: calc(100vw - 48px)`, aber hoechstens 2512px Breite.

1440px
1200px wirkt gross
2560px
1200px bleibt fix
3840px
mehr Rand, nicht breiter

XS - 420px

Kurze Bestaetigung oder knapper Hinweis.

Mitarbeiter deaktivieren?

Der Zugriff wird sofort gesperrt. Bestehende Daten bleiben erhalten.

Abbrechen Deaktivieren

S - 560px

Kleines Formular mit wenigen Feldern.

Abbrechen Anlegen

M - 720px

Normales Formular mit mehreren Feldern oder kurzer Section-Struktur.

Abbrechen Weiter

L - 1200px max

Grosser Editor mit Navigation, Suche und komplexeren Einstellungen. Nutzt die 32px Dialog-Variante.

Role

General

Contacts

Reports

Advanced

Contacts

Read, create and update contact records.

Reports

View exported reports and analytics.

Abbrechen Rolle speichern

D08 Dialog Internal Gaps

Validierte Entscheidung: Balanced ist der Standard. Diese Werte betreffen nur Abstaende zwischen Elementen innerhalb normaler Dialoge, nicht die bereits validierte Dialogbreite oder das Dialog-Padding.

Entscheidung D08 validiert

Was du festlegst

Welche Gaps gelten zwischen Dialog-Header, Body, Feldern, Sections und Footer?

Bereits validiert: Dialog Padding 16px Default und 32px Spacious. Jetzt validiert: Balanced ist die Standard-Gap-Logik fuer normale Dialoge, damit Dialoge nicht je Screen unterschiedlich wirken. Mehrzeilige Texte nutzen die 150%-Texttoken; dadurch wird der Textblock selbst hoeher, ohne zusaetzlichen Sonder-Gap.

Kompakt Sehr dicht. Gut fuer kurze Confirm-Dialoge, aber fuer Formulare schnell gedrueckt.
Balanced Orientiert sich an 8px-Rhythmus und Carbon-nahem Modal-Denken: kompakt, aber lesbar.
Ruhig Mehr Luft fuer groessere Dialoge, kann bei XS/S aber zu luftig wirken.
Entschieden: Balanced wird Standard. Title Gap 8px, Field Gap 16px, Section Gap 24px, Button Gap 8px.

Kompakt

Fuer sehr kurze Dialoge. Spart Hoehe, trennt Inhalte aber weniger stark.

  • Title -> Description4px
  • Field/Form Row Gap12px
  • Section Gap20px
  • Footer Button Gap8px

Balanced

Validierter Default. Passt zu 16px Dialog-Padding und bleibt nah an D02.

  • Title -> Description8px
  • Field/Form Row Gap16px
  • Section Gap24px
  • Footer Button Gap8px

Ruhig

Mehr Luft fuer grosse Dialoge. Koennte eher zur 32px-Spacious-Variante passen.

  • Title -> Description8px
  • Field/Form Row Gap20px
  • Section Gap32px
  • Footer Button Gap12px
Zusatzfrage validiert

Footer Buttons

Sollen Buttons in kleinen Dialogen rechts ausgerichtet bleiben oder die Breite fuellen?

Das ist getrennt vom Button-Gap. Es geht um die Button-Verteilung im Footer: klassische Desktop-Dialoge richten Actions oft rechts aus; bei sehr kleinen Dialogen kann Fill ergonomischer wirken.

Default: rechts Alle Dialoggroessen behalten rechts ausgerichtete Actions. Ruhig und desktop-typisch.
XS/S: Fill Nur kleine Dialoge mit genau zwei Actions duerfen beide Buttons gleich breit fuellen.
Immer Fill Sehr klare Buttonflaechen, aber fuer M/L-Dialoge meistens zu dominant.
Entschieden: Footer Actions bleiben standardmaessig rechts ausgerichtet. XS/S-Fill bleibt nur eine optionale Sondervariante, falls sie spaeter bewusst gebraucht wird.

Default: rechts ausgerichtet

Klassischer Desktop-Dialog. Der freie Bereich links ist bewusst, weil die Actions nicht mit dem Inhalt konkurrieren.

XS/S Sonderfall: Fill Buttons

Kann bei sehr kleinen Dialogen mit genau zwei Actions sinnvoll sein. Sollte keine globale M/L-Regel werden.

D09 States / Component Ownership

Klarstellung: States sind inline Inhaltszustaende und werden ueber Komponenten abgedeckt. Sie sind keine Modale und aktuell keine eigene Layout-Entscheidung in D-D0b.

Komponenten-Ownership

Was hier gemeint ist

Empty, Error und No-Permission ersetzen inline den betroffenen Inhaltsbereich.

Beispiel: Eine leere Tabelle zeigt einen Empty State im Tabellen- oder Listenbereich. Ein Ladefehler zeigt einen Error State im betroffenen Bereich. Das oeffnet nicht automatisch einen Dialog.

Empty State Im Komponenten-Index vorhanden: Data Display / Empty State.
Error State Im Komponenten-Index vorhanden: Feedback / Error State bzw. Partial page failure.
No Permission Nicht als eigene lokale Komponenten-MD gefunden. Falls noetig als Variante/Komponente klaeren.
Keine neue D09-Layout-Regel: Screens sollen die vorhandenen State-Komponenten verwenden. No-Permission muss bei Bedarf als Komponentenfrage validiert werden.

Empty

No roles have been created yet.

Create role

Error

The list could not be loaded.

Try again

No permission

You do not have access to this area.

Back to overview